API Gateway provee un sistema básico para validar los query parameters (parámetros de consulta) y los headers (encabezados) de tu petición.
Primero lo primero, necesitas una API con una Lambda. En caso de que quieras aprender como hacer una en AWS desde 0, puedes revisar Como crear una REST API con Lambda en AWS en 6 pasos.
Una vez puedas llamar a una Lambda con tu API, puedes volver y continuar con los siguientes pasos.
En este ejemplo tengo una API llamada SampleAPI y un recurso llamado sample con un método GET.
Para empezar debes acceder a la sección de Solicitud de método del método GET del recurso en cuestión.
En esta sección como el nombre lo indica puedes configurar los requerimientos para llamar al método. Esto incluye opciones de autorización y de validación del body (cuerpo), headers y query params. Como ya sabes por el momento nos enfocaremos en los últimos 2.
Query Parameters (Parametros de consulta)
Los query params son parámetros en las URL que tienen asociado algun valor.
Un ejemplo sería algo así:
https://example.com/cars?color=red&type=small
Esta URL tiene 2 query params:
Query Param (Parámetro de Consulta) | Valor |
color | red |
type | small |
Como te imaginarás esto sirve para pasarle valores al back-end y que se pueda filtrar o procesar la información en base a estos parámetros.
Volviendo a API Gateway. Ahora haz clic en “Parámetros de cadenas de consulta de URL” y agrega una cadena de consulta.
En este ejemplo agregaré 3 parámetros y marcaré 2 como obligatorios:
* Seguramente habrás notado la columna de Almacenamiento en caché. Esta opción sirve para precisamente guardar en caché el resultado de un request, mejorando su velocidad de respuesta en futuras llamadas durante un cierto periodo de tiempo.
AWS mostrará la siguiente advertencia en la columna “Obligatorio”
Para solucionarlo hay que hacer precisamente lo que AWS indica. Configura la opción de Validador de Solicitudes de la siguiente manera:
Si no habilitas esto API Gateway no validará nada aunque lo hayas configurado en las otras secciones.
Una vez tienes configurados los parámetros que quieres que sean obligatorios debes implementar el API para poder probarlo.
*Recuerda que para implementar tu API, debes seleccionar Acciones->Implementar la API
Probando la validación de parámetros
Veamos como se comporta nuestro API con los nuevos cambios.
*Para hacer las pruebas te recomiendo utilizar un cliente como Postman o Insomnia. Si como yo usas VsCode te recomiendo el plugin de ThunderClient.
Al hacer una llamada con todos los parámetros verás que efectivamente la petición funciona correctamente:
Sin embargo si haces una llamada sin ningun parámetro API Gateway devolverá un error:
Precisamente ese es el comportamiento que esperabamos. Como ya te habrás dado cuenta el parámetro que no se marcó como obligatorio es irrelevante. No importa si lo pasas o no en la llamada.
Headers (Encabezados)
Los headers son otra forma de recibir valores de un request. Usualmente se usan para almacenar meta-datos acerca de la petición.
Por lo general se utilizan para guardar información acerca de autorización, cookies, cache o del formato de respuesta esperado. Sin embargo nada te impide usarlos para pasar algún dato adicional que tu quieras. A diferencia de los query params estos valores no son visibles en la URL.
Para configurar los headers dirígete a la misma sección en donde configuraste los query params y selecciona la opción de “Encabezados de solicitud HTTP”.
En mi caso hice lo mismo que con los query params y también agregué 3 headers, marcando 2 como obligatorios:
Dado que haz modificado el API necesitas volver a mandar a llamar la opción de Implementar la API, para que los cambios se reflejen en la versión publicada.
Aseguraté de que la Etapa que hayas creado este usando la última implementación que hayas agregado.
*Es de extrema utilidad poner una buena descripción al momento de Implementar la API para que puedas encontrar la implementación correcta en el listado.
Si mandas a llamar el endpoint con los mismos parámetros que la vez anterior ahora obtendrás un error:
Si te fijas el error es el mismo que arroja AWS cuando no agregas los query params necesarios. No te dejes engañar, el API mostrará el mismo error aunque añadas las llaves que te indica en los query parameters:
A pesar de que el error no especifíque en donde deben colocarse los parámetros que faltan tu sabes que hacen falta en los headers. Al agregarlos y realizar nuevamente la llamada, obtendrás una petición exitosa.
*Thunder Client agrega automáticamente los 2 primeros headers al request. No es necesario que los agregues.
Listo haz aprendido a validar headers y query params obligatorios en tu API. API Gateway se encarga de hacer esta validación por ti y ni siquiera se molesta en llamar a la Lambda si la petición no cubre los requisitos mínimos que le indiques.
Evidentemente hay validaciones más complejas que podrías hacer como requerir forzosamente 1 de 2 parámetros o permitir solo valores numéricos. Para esta clase de validaciones si necesitarás procesar la información y por ende es más común que se haga dentro de tu función Lambda.